%% main.tex --- файл-обертка для диплома

\documentclass[russian,utf8,simple,floatsection,equationsection]{eskdtext} 

\include{defs}  % вставляем содержимое служебных инструкций из defs.tex

\setcounter{section}{4}

\ESKDcolumnII{\normalsize{Разработка ПО}}

\begin{document}
\section{Разработка ПО.}
\subsection{Процесс и методология разработки ПО}
Разработка программного обеспечения (англ. software engineering,
software development) — это род деятельности (профессия) и процесс,
направленный на создание и поддержание работоспособности программного
обеспечения, используя технологии и практики из информатики,
управления проектами, математики, инженерии и других областей
знания. Как и другие, традиционные инженерные дисциплины, разработка
программного обеспечения имеет дело с проблемами стоимости и
надёжности. Некоторые программы содержат миллионы строк исходного
кода, которые, как ожидается, должны правильно исполняться в
изменяющихся условиях. Сложность ПО сравнима со сложностью наиболее
сложных из современных машин. (Боинг 777-200 насчитывает примерно
132,5 тыс. уникальных деталей. Если учесть каждую заклёпку и каждый
винт, можно говорить о более чем 3 млн. деталей \red{[3]}.) 

На протяжении нескольких десятилетий стоит задача поиска повторяемого,
предсказуемого процесса или методологии, которая бы улучшила
продуктивность и качество разработки. Одни пытались систематизировать
и формализовать этот, по-видимому, непредсказуемый процесс. Другие
применяли к нему методы управления проектами. Без четкого управления,
разработка ПО выходит из-под контроля, съедая лишнее время и
средства.

Процесс разработки программного обеспечения (англ. software
development process, software process) — структура, согласно которой
построена разработка программного обеспечения (ПО).

Модель водопада (англ. waterfall model) - модель процесса разработки
программного обеспечения, в которой процесс разработки выглядит как
поток, последовательно проходящий фазы анализа требований,
проектирования, реализации, тестирования, интеграции и поддержки. В
качестве источника названия <<водопад>> часто указывают статью,
опубликованню У.У.Ройсом (W. W. Royce) в 1970 году; забавно, что сам
Ройс использовал итеративную модель разработки и даже не использовал
термин <<водопад>>\red{[2]}. 

\subsection{Анализ информационных потоков для разработки ПО}
Рассмотрим подробнее этап проектирования программы. Для этого опишем
общую структуру системы, представленную на red{рисунке 4.1}.

\section*{bla - bla - bla}

\subsection{Проектирование базы данных}
\subsubsection{Системный анализ}
Следующим этапом разработки программного обеспечения является
проектирование базы данных.

Основными этапами проектирования базы данных являются:
\begin{itemize}
\item системный анализ;
\item инфологическое проектирование;
\item логическое проектирование.
\end{itemize}

Сутью системного анализа является определение задач, которые решаются
в системе и для кого. Представим объекты системы:

\section*{bla - bla - bla}

\subsubsection{Инфологическое проектирование}
Инфологическая модель применяется на втором этапе проектирования БД,
то есть после словесного описания предметной области. При разработке
серьезных корпоративных информационных систем проект базы данных
является тем фундаментом, на котором строится вся система в
целом. Следовательно, инфологическая модель должна включать такое
формализованное описание предметной области, которое легко будет
<<читаться>> не только специалистами по базам данных, и это описание
должно быть настолько емким, чтобы можно было оценить глубину и
корректность проработки проекта БД, и конечно оно не должно быть
привязано к конкретной СУБД. Инфологическое проектирование, прежде
всего, связано с попыткой представления семантики предметной области в
модели БД. Реляционная модель данных в силу своей простоты и
лаконичности не позволяет отобразить семантику, то есть смысл
предметной области. Ранние теоретико-графовые модели в большей степени
отображали семантику предметной области. Они в явном виде определяли
иерархические связи между объектами предметной области. Проблема
представления семантики давно интересовала разработчиков, и в
семидесятых годах было предложено несколько моделей данных, названных
семантическими моделями. К ним можно отнести семантическую модель
данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLean) в 1981
году, функциональную модель данных Шипмана (Shipman), также созданную
в 1981 году \red{[5]}, модель <<сущность-связь>>, предложенную Ченом (Chen) в
1976 году, и ряд других моделей. У всех моделей были свои
положительные и отрицательные стороны, но испытание временем выдержала
только последняя. И в настоящий момент именно модель Чена
<<сущность-связь>>, пли <<Entity Relationship>>, стала фактическим
стандартом при инфологическом моделировании баз данных. Общепринятым
стало сокращенное название ER-модель, большинство современных
CASE-средств содержат инструментальные средства для описания данных в
формализме этой модели. Кроме того, разработаны методы автоматического
преобразования проекта БД из ER-модели в реляционную, при этом
преобразование выполняется в дата-логическую модель, соответствующую
конкретной СУБД. Все CASE-системы имеют развитые средства
документирования процесса разработки БД, автоматические генераторы
отчетов позволяют подготовить отчет о текущем состоянии проекта БД с
подробным описанием объектов БД и их отношений, как в графическом
виде, так и в виде готовых стандартных печатных отчетов, что
существенно облегчает ведение проекта.  

В настоящий момент не существует единой общепринятой системы
обозначений для ER-модели и разные CASE-системы используют разные
графические нотации, но разобравшись в одной, можно легко понять и
другие нотации \red{[5]}.

\emph{Модель <<сущность—связь>>}

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model или
entity-relationship diagram ) — это модель данных, позволяющая
описывать концептуальные схемы. Она предоставляет графическую нотацию,
основанную на блоках и соединяющих их линиях, с помощью которых можно
описывать объекты и отношения между ними какой-либо другой модели
данных. В этом смысле ER-модель является мета-моделью данных, то есть
средством описания моделей данных. Как любая модель, модель
<<сущность—связь>> имеет несколько базовых понятий, которые образуют
исходные кирпичики, из которых строятся уже более сложные объекты по
заранее определенным правилам. Эта модель в наибольшей степени
согласуется с концепцией объектно-ориентированного проектирования,
которая в настоящий момент, несомненно, является базовой для
разработки сложных программных систем \red{[6]}.

В основе ER-модели лежат следующие базовые понятия:
Сущность имеет имя, уникальное в пределах моделируемой системы. Так
как сущность соответствует некоторому классу однотипных объектов, то
предполагается, что в системе существует множество экземпляров данной
сущности. Объект, которому соответствует понятие сущности, имеет свой
набор атрибутов — характеристик, определяющих свойства данного
представителя класса. При этом набор атрибутов должен быть таким,
чтобы можно было различать конкретные экземпляры сущности. Например, у
сущности Сотрудник может быть следующий набор атрибутов: табельный
помер, фамилия, имя, отчество, дата рождения, количество детей. Набор
атрибутов, однозначно идентифицирующий конкретный экземпляр сущности,
называют ключевым. Для сущности Сотрудник ключевым будет атрибут
табельный номер, поскольку для всех сотрудников данного предприятия
табельные номера будут различны. Экземпляром сущности Сотрудник будет
описание конкретного сотрудника предприятия. Одно из общепринятых
графических обозначений сущности - прямоугольник, в верхней части
которого записано имя сущности, а ниже перечисляются атрибуты. Между
сущностями могут быть установлены связи - бинарные ассоциации,
показывающие, каким образом сущности соотносятся или взаимодействуют
между собой. Связь может существовать между двумя разными сущностями
пли между сущностью и ей же самой (рекурсивная связь). Она показывает,
как связаны экземпляры сущностей между собой. Если связь
устанавливается между двумя сущностями, то она определяет взаимосвязь
между экземплярами одной и другой сущности. Например, если у пас есть
связь между сущностью <<Студент>> и сущностью <<Преподаватель>> и эта
связь — руководство дипломными проектами, то каждый студент имеет
только одного руководителя, но один и тот же преподаватель может
руководить множеством студентов-дипломников. Поэтому это будет связь
<<один-ко-многим>> (1:$\infty$), один со стороны <<Преподаватель>> и многие со
стороны <<Студент>>. Связи делятся на три типа по множественности:
одип-к-одпому (1:1), один-ко-многим (1:$\infty$), многие-ко-многим
($\infty$:$\infty$). Связь один-к-одпому (1:1) означает, что экземпляр одной
сущности связан только с одним экземпляром другой сущности. Связь (1:
$\infty$) означает, что один экземпляр сущности, расположенный слева по
связи, может быть связан с несколькими экземплярами сущности,
расположенными справа по связи. А связь <<многие-ко-многим>> ($\infty$:$\infty$)
означает, что один экземпляр первой сущности может быть связан с
несколькими экземплярами второй сущности, и наоборот, один экземпляр
второй сущности может быть связан с несколькими экземплярами первой
сущности.  

Между двумя сущностями может быть задано сколько угодно связей с
разными смысловыми нагрузками.

На основе этих данных опишем сущности, присутствующие в базе данных.

\section*{bla - bla - bla}

В результате построения модели предметной области в виде набора
сущностей и связей получаем связный граф.

\subsubsection{Логическое проектирование}

\section*{bla - bla - bla}




\end{document}
